The modern cable network has evolved a long way from its humble beginnings. In 1948, the first community antenna system delivered television signals over twin-lead strung from house to house. In 1950, a coax system was built in which the coax cable was strung on utility poles. These systems were intended to solve reception problems caused by weak signals (rural areas) or by ghosting from multiple reflected signals (urban areas). In the seventies, communications satellites breathed new life into the cable industry by providing access to programming not otherwise available in the cable operator's service area.
Until recently, the cable network was still predominantly a vehicle for delivering entertainment. With the advent of the Internet and the rise in demand for broadband two-way access, the cable industry began to seek ways of utilizing its existing plant. Pure coax cable networks were replaced with hybrid fiber networks (HFNs) using optical fiber from the headend to the demarcation with the subscriber coax (usually at a fiber node).
A major problem for a cable operator desiring to provide digital service was the configuration of its network. Designed for one-way delivery of broadcast signals, the existing cable network topology was optimized for downstream (toward the subscriber) only service. New equipment would have to be added to the network to provide two-way communication. To reduce the cost of this equipment and to simplify the upgrade of the broadcast cable for two-way digital traffic, standards were developed for a variety of new cable-based services. The first of these standards, the Data Over Cable System Interface Standard (DOCSIS), was released in 1998. DOCSIS establishes standards for cable modems and supporting equipment.
A DOCSIS compliant modem (DCCM) must be “provisioned” before the DCCM may be operated on the network. Provisioning involves a process by which a network device is initialized, authenticated, registered, and configured to operate with a cable network. A network device receives a boot file as part of the provisioning process.
Referring to FIG. 1, the provisioning of a DOCSIS-compliant cable modem (DCCM) with a boot file is illustrated. Each time a DCCM is powered-on or reset, it must be initialized 100 through a series of “handshakes” and transfers of data between itself and a cable modem termination system (CMTS) at the cable headend. During this process, the DCCM receives channel and sync information to allow it to establish communications with the CMTS. It also receives a temporary service identification (SID) number. The modem power is set and the CMTS and the DCCM are now “known” to each other and able to communicate.
Following initialization, the DCCM is then authenticated 120 to confirm that the DCCM is entitled to receive service. The next provisioning step is registration 130, where the DCCM is configured as an Internet device. During this process, the DCCM synchronizes its clock with that of the CMTS and obtains an Internet protocol (IP) address from a Dynamic Host Configuration Protocol (DHCP) server. The DHCP server also provides the DCCM the network address of a Trivial File Transfer Protocol (TFTP) server and where a device configuration file (or “boot file”) for that modem can be found and downloaded. The DCCM requests its device boot file 140 by the sending the TFTP a request message comprising a device boot file filename. Upon receipt of the device boot file, the DCCM sends a registration request (REG-REQ) to the CMTS. This REG-REQ includes the current service identification (SID), IP address, operational attributes, upstream and downstream channel IDs, time stamps, and other configuration settings, as well as a message integrity check (MIC) value (described below). If the information is accepted, the CMTS responds with a new SID and completes the registration process.
In general, then, the CMTS is not configured with the attributes of its DCCMs. Rather, the CMTS will acquire these attributes and the attribute values through the registration request message.
In a DOCSIS environment, the device boot file comprises device attributes that are expressed in type-length-value (TLV) format and information necessary for the DCCM to operate on the cable network to which it is connected. By way of illustration, attributes identified by the DOCSIS standard for a DCCM include the maximum upstream and downstream data rates (based on the service level to which the customer has subscribed), the number of devices supported by the DCCM that require IP addresses, and information necessary to identify and authenticate the DCCM to the cable network. The device boot file is received by the DCCM in binary format. The DCCM uses the device boot file to populate device attributes with specific values.
As previously noted, the boot file provided by the TFTP server to the DCCM includes a message integrity check (MIC) value. The MIC is an MD-5 hash of certain device attributes plus a shared secret. The CMTS uses the same shared secret used by the TFTP server and the device attributes in the REG-REQ message it receives from the DCCM to compute the MIC value. The CMTS then compares the MIC value it computed to the MIC value computed by the TFTP server and included in the REG-REQ message sent by the DCCM. If the MIC values match, the registration request is granted. If the MIC values do not match, the registration request is denied.
In order for the MIC process to be effective, the TFTP server and the CMTS must use the same shared secret. Changing the shared secret is not a simple task. Currently, updating the shared secret in the CMTS is a manual process fraught with possibilities for human error. An operator typically manually logs into each of the CMTSs one after another to update the shared secret value. Most CMTSs in use today CMTSs permit up to two shared secrets to be stored at one time. If the CMTSs used by an MSO permit only one shared secret to be stored, the shared secret is first removed from the CMTS. The CMTS will then ignore the MIC and continue to register CMs, albeit without the security offered by the shared secret and the MIC. The old shared secret on the DCS is replaced with a new shared secret. Finally, the new shared secret is added to each CMTS supported by the DCS.
If the CMTSs used by the system operator allows two shared secrets to be stored, the new shared secret will be stored on the CMTS leaving the original shared secret value in place. Once all of the CMTSs are configured with both the old and new shared secret value, the boot file server configuration is changed so that the new shared secret value is used. Then the old shared secret value is removed from each CMTS supported by the DCS. Due to the manual nature of the process, mistakes are unavoidable, resulting in service problems, inefficient use of engineering time, and a bias against modification of provisioning parameters. Further, until all of the CMTSs have been updated with the new shared secret, some registration requests will be accepted using an old, and possibly compromised, shared secret.
Under the DOCSIS standards, the traffic that a DCCM may send and receive may be regulated at the DCCM by filters set to either “pass” or to “do not pass” traffic based on IP address (source or destination), port (source or destination), protocol, or packet type (multicast or unicast). The filter group that is enforced at a DCCM is determined by bootfile attributes that can be set in the static file. Use of filters at the DCCM offers the system operator a reasonable level of protection from intentional and unintentional behavior of its subscribers. Port filters, for example, protect the network from a rogue DCHP server established on a subscriber's customer premises equipment (CPE) by permitting only DHCP client transactions through the DCCM. DHCP client activity requires the DCCM to permit inbound (to the CPE) packets destined to port 68 on the DHCP client (located on the CPE) and outbound packets destined to port 67 on the DHCP server. The DHCP filter blocks all other combinations of ports 67 and 68 to prohibit subscribers from running their own DHCP server in competition with the DHCP server of the system operator. Blocking these other combinations permits a subscriber to run a DHCP server on its CPE without interfering with the operation of the network.
Similarly, access to other DCCMs on the network can be prevented by setting the IP filter to block access to the IP addresses that are not routable. As most DCCMs are provisioned with non-routable IP addresses (e.g., in the form 10.x.x.x), setting a filter to preclude access to these addresses can provide a measure of security against one subscriber “snooping” another subscriber's DCCM.
However, depending on filters at the DCCM for security is not risk free. The DCCM is not under control of the network operator and a determined subscriber may defeat the filter settings with serious results. Additionally, the development of CPU controlled cable modems (CCCMs) increases the vulnerability of the filter configuration to tampering. For this reason, the more desirable location for filter enforcement is the CMTS. In this implementation, filter settings are established at the CMTS and arranged by type and by groups within filter types. The DOCSIS boot file attributes relating to filter groups may include four indices:                one identifying the upstream filter group for packets originating from the cable modem (i.e., those packets whose source MAC address matches that of the cable modem).        one identifying the upstream filter group for packets originating from subscribers attached to the cable modem (i.e., those packets whose source MAC address does not match that of the cable modem).        one identifying the downstream filter group for packets destined to the cable modem (i.e., those packets whose destination MAC address matches that of the cable modem).        one identifying the downstream filter group for packets destined to subscribers attached to the cable modem (i.e., those packets whose destination MAC address does not match that of the cable modem).        
A subscriber is assigned to a filter group based on policies established by the network operator and by requirements established by the Internet service provider (ISP) that services a subscriber. As in the case of the shared secret, once a filter group is defined, changing the filter group definition is a difficult and risky operation.
Typically, DOCSIS device boot files are pre-generated and stored in a file library on a server as static files. Thus, a device boot file is created for each possible configuration of a network device. The permutations of the various service levels coupled with other subscriber-specific elements makes management of this library a significant task. Additionally, large networks must maintain multiple file library servers, requiring that all servers be updated with changes to the file library. In order to establish a new configuration for a device, even for a single customer, a new device boot file must be added to the file library and populated to all of the boot file library servers.
Service providers are increasingly moving toward dynamically generating boot files based upon the content of the device boot file request message. (A dynamic TFTP (DTFTP) server meeting the requirements of the present invention is described in commonly owned U.S. Pat. No. 7,293,078, entitled “System And Method For Provisioning A Provisionable Network Device With A Dynamically Generated Boot File Using A Server” and filed Jul. 14, 2003, which application is incorporated herein in its entirety and for all purposes.) For example, a DTFTP server may parse the file name of the device boot file in the device boot file message to determine what configuration attributes are required in the device boot file and what values are to be assigned to those attributes.
While the introduction of DTFTP servers for boot file generation greatly improves the ability of service providers to manage boot file generation, use of DTFTP servers alone does not solve problems of managing changes in provisioning parameters that affect the boot file generation server and the CMTS. What is needed is a system and method for updating and synchronizing changes in provisioning parameters used by DTFTP by servers and CMTSs that does not require manual intervention.